Conventional CRC operation involves processing a data stream against a known CRC polynomial that yields a result that is nearly unique to that data stream. Modifications of bits in the data stream cause different CRC results. Consequently, if data is corrupted in delivery of the stream, the calculated CRC results will not match the expected CRC results. The width and values in the polynomial determine the strength (uniqueness) of the CRC. A next-state decoder (NSD) implements the calculation of the CRC polynomial against the incoming data. The CRC is widely applicable in many situations, for example, in endeavors that transmit, receive, store, retrieve, transfer, or otherwise communicate electronically represented digital information.
According to conventional CRC operation, and as shown in FIG. 1, a syndrome 11 contained in a feedback register (FB REG) 12 is fed back to the syndrome input 10 of the NSD 14. The NSD 14 also receives the current piece of incoming data 13. The resulting output 15 of the NSD 14 is registered into the feedback register 12, and thus becomes the next syndrome at 11 for the NSD 14 to use with the next set of incoming data at 13. The initial state of the feedback register 12 (i.e., the initial syndrome value 11) is set to an appropriate value for the CRC polynomial that has been selected for use. A checksum generator 16 performs a predetermined operation on the final syndrome value 11 contained, in the feedback register 12 after all of the incoming data 13 has been processed. The checksum generator 16 produces a CRC checksum value 17. The checksum value determined by the checksum generator 16 could be associated with (e.g., concatenated with, appended to, etc.) the data 13 for transmission, transfer, storage, etc., together with, the data. An example would be a transmit packet having a checksum field associated with, its data (payload) portion. The checksum value determined by the checksum generator 16 could be compared to a further checksum value that has been received, retrieved, etc., together with the data 13. An example would be a received packet whose checksum field contains the further checksum value and whose data (payload) portion contains the data 13. Comparison of the further checksum value to the checksum value determined by the checksum, generator 16 provides a basis for evaluating the validity of the received data 13.
The operation, performed by any given NSD (such as NSD 14) conventionally requires a single specific input data width. For example, the NSD 14 is specifically designed to operate on the parallel data width (e.g., bus width) supported by the data input 13. However, if a data block, (e.g., the data payload portion of a packet) received at input 13 is naturally aligned on boundaries that differ from the data width required by the NSD 14, then at least one of the first-received and last-received parallel sets of data within the block cannot be guaranteed to comply with the NSD's required data width. The parallel sets of data in the block between the starting and ending sets will of course comply with the required data width. The aforementioned width misalignment between the format of the received data block and the input data width of the NSD prevents the NSD from properly determining the final syndrome for the received data block. The input data width (e.g., at data input 13 of NSD 14) could be set to the narrowest data width that the misaligned data block is expected to present, but this effectively limits the width of the input data stream, and can thus impose a corresponding limit on data throughput in the CRC processing.
It is therefore desirable to provide a solution to the above-described problems of width misalignment between the format of the input data block and the input data width of the NSD.